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What  Does  the  SEI  Acquisition  Support 
Program  (ASP)  Do? 


The  Acquisition  Support  Program  (ASP)  helps 
Department  of  Defense  (DoD)  and  other  government 
acquirers  make  evolutionary  and  revolutionary 
improvements  in  the  acquisition  of  software-intensive 
systems,  and  provides  opportunities  for  SEI  programs 
to  create,  apply,  and  amplify  new  technologies. 
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Acquisition  Business  Questions? 

“How  can  I  . . . 

...  identify  and  manage  the  risks  that  beset  my 
project?” 

...  develop  and  manage  requirements?” 

...  create  an  acquisition  strategy  best  suited  for  my 
program?” 

...  ensure  that  my  software  acquisition  is  integrated 
with  the  whole  system”? 

...  create  a  software  architecture  that  meets  the  needs 
of  my  project?” 

...  effectively  monitor  the  progress  of  my  acquisition?” 

...  continuously  improve  my  software  acquisition  efforts?” 
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SEI  Acquisition  Support  Program 


Process 


S/W  Engineering 


Sys  Engineering 


Architecture 


Interoperability 


Security 


Real-time 


Department  of 

Defense 

Programs 


Civilian 

Agency 

Programs 


Knowledge 
Integration,  and 
Transfer 
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Improved 

Systems 


Improved  State 
of  Practice 
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Acquisition  Support  Program 


Purpose 

•  Accelerate  adoption  of  improved  practices  for  acquiring, 
deploying,  and  sustaining  software-intensive  systems 

Tasks 

•  Enable  key  acquisition  programs 
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to  achieve  their  objectives 
•  Capture  and  integrate 
knowledge  from 
engagements  with 
acquisition  organizations 
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ASP  Program  Goals 

Drawing  on  our  expertise  in  software  engineering,  help 
DoD  and  other  government  acquirers  improve  their 
ability  to  acquire,  deploy,  and  sustain  systems  and 
capabilities. 

Identify  opportunities  for  the  Software  Engineering 
Institute  (SEI)  to  create,  apply  and  amplify 
technologies  that  respond  to  customer  needs. 

Disseminate  lessons  learned  and  best  practices 
through  courses,  workshops,  conferences, 
publications,  and  participation  in  acquisition 
communities  of  practice. 
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ASP  Program  Strategies 


•  Understand  and  characterize  the  acquisition 
environment  ( Needs  Analysis). 

•  Work  directly  with  key  acquisition  programs  to 
help  them  achieve  their  objectives  ( Acquisition 
Improvement). 

•  Disseminate  lessons  learned  and  best  practices 
through  courses,  workshops,  conferences, 
publications,  and  participation  in  acquisition 
communities  of  practice  ( Knowledge  Integration 
and  Transfer). 
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ASP  Operational  Approach 


Acquisition 

Support 

Program 


applies 

Software  and  Systems 
Technologies 


Direct  Benefit  to 
Acquisition  Programs 


Indirect  Benefit  to 
Similar  Programs 


Feedback  from  direct  support 
and  community  learning 
improves  ASP  practices  &  SEI 
technologies 


Workshops,  Classes,  Seminars 
Tailored  learning  via 
Acquisition  Communities  of 
Practice 

•  Army,  Navy,  Air  Force,  Defense  Agencies 

•  Software  Collaborator’s  Network 

•  STSC 

•  MITRE,  Aerospace,  APL 

•  DAU 

•  OSD  Best  Practices 

•  Civil  Agencies 

•  Universities 

•  US-UK-AUS  SISAIG 
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CMMI  and  Acquisition 


*  CMMI  Acquisition  Module  (CMMI-AM) 

-  Example  of  Create,  Amplify,  Apply 

-  Piloted  with  multiple  DoD  program  offices 

-Large  and  small  size 

-Various  life  cycle  stages 

-  Version  1.1  released  in  May  2005 

-  CMMI-AM  course  now  in  curriculum 

•  CMMI  Acquisition  Constellation  or  CMMI-A 

-  In  requirements  development  phase 
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CMMI  Module  for  Acquisition  ver  1.1 
Process  Areas 


Project 

Management 


Engineering 


Support 


•  Project  Planning 

•  Project  Monitoring 
and  Control 

•  Solicitation  & 
Contract  Monitoring* 

•  Integrated  Project 
Management 

•  Risk  Management 


•  Requirements 
Management 

•  Decision  Analysis  and 
Resolution 

•  Requirements 
Development 

•  Measurement  and 
Analysis 

•  Verification 

•  Transition  to 
Operations  &  Support* 

•  Validation 

•  Note  two  new  CMMI-AM 
process  areas  are  in  Bold  Type 
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CMMI  Module  for  Acquisition  Ver  1 .1 
Generic  Goals  and  Practices 


Generic  Goals 

Generic  Practices 

Institutionalize  a 
Managed  Process 

Establish  an  Organizational  Policy 

Plan  the  Process 

Provide  Resources 

Assign  Responsibility 

Train  People 

Manage  Configurations 

Identify  and  Involve  Relevant  Stakeholders 

Monitor  and  Control  the  Process 

Objectively  Evaluate  Adherence 

Review  Status  with  Higher  Level  Management 

Institutionalize  a 
Defined  Process 

Establish  a  Defined  Process 

Collect  Improvement  Information 

©2005  by  Carnegie  Mellon  University 


Version  1.0 


CMM  Technology  Conference  Nov  2005  12 


Carnegie  Mellon 

Software  Engineering  Institute 

CMMI  Acquisition  Constellation 
(CMMI-A) 

•  To  be  built  on  common  CMMI  ve rl  .2  architecture 

framework  and  will  include: 

-  the  primitive  or  base  CMMI  model  (ver.1.2) 

-  groups  of  amplifications  for  acquisition 

-  groups  of  elaborations  for  acquisition 

-  groups  of  additions  for  acquisition 

•  Development  will  be  in  parallel  with  CMMI  ver.1.2 

•  Deployment  will  be  after  CMMI  ver.1.2  is 
released 

-  CMMI  ver.1.2  scheduled  for  release  in 
Q3  or  Q4  CY  2006 

-  CMMI-A  forecast  for  release  sometime  in 
CY  2007 
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CMMI-A  Current  Status 


•  Currently  in  requirements  development  phase 

•  SEI  coordinating  effort,  building  upon 

-  Existing  CMMI  Acquisition  Module 
(CMMI-AM) 

-  General  Motors  IT  Sourcing  expansion 

-  Will  add  government  perspectives  from  both 
DoD  and  civil  agencies 
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Software  Acquisition  Survival  Skills 


Course  developed  to  integrate  key  issues  identified 
in  government  acquisitions.  Issues  identified  via: 

•  Independent  Technical  Assessments  (ITAs)  performed 
by  the  SEI 

•  Informal  survey  of  acquisition  professionals 

•  Literature  review 


Target  audience  is  acquisition  project  office  staff 


Topics  include: 

•  Risk  Management 

•  Systems  Engineering 

•  Architecture 

•  Process  Management 


Pre-Award  Activities 
Technical  Evaluation 
Metrics 

Requirements  Management 
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SW  Survival  Skills  Modules 

Based  on 

•  Review  of  CM  Ml  process  areas  and  specific 
practices 

•  Presentation  of  acquisition  amplifying 
information 

•  Identification  of  symptoms 

•  Suggesting  prevention  approaches 

•  Giving  practical  tips  on  what  to  do  next 
(tailored  to  where  you  are  in  the  process) 
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Today:  Two  Representative 

Process  Areas 

Requirements  Management  &  Risk  Management 
For  each: 

-  Specific  practices 

-  Sample  work  products 

-  Sample  key  issues 

-  Symptoms  of  problems 

-  Prevention  strategies 

-  What  to  do  now  (depending  on  where  you 
are) 
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Requirements  Management  Purpose 


The  purpose  of  requirements  management  is  to 
manage  the  requirements  of  the  project’s  products  and 
product  components  and  to  identify  inconsistencies 
between  those  requirements  and  the  project’s  plans  and 
work  products. 

For  Acquisition,  requirements  management  is  applied  to 
the  requirements  that  are  received  from  the 
requirements  development  process. 
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Acquisition  Requirements  Management 


During  acquisition,  requirements  management  includes 

•  the  direct  management  of  acquirer-controlled 
requirements 

•  oversight  of  supplier  requirements  management 

Requirements  are  managed  and  maintained  with 
discipline  so  that  changes  are  not  executed  without 
recognizing  the  impact  to  the  project. 

Requirements  management  does  not  end  with  the 
selection  of  a  supplier  and  an  award. 

•  the  acquisition  project  continues  to  manage  high-level 
requirements,  including  changes 

•  the  selected  supplier  manages  the  lower  level 
requirements 
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Requirements  Management 
Goal  and  Practices 


Specific  Goal  Specific  Practice 


Manage 

Requirements 


Obtain  an  Understanding  of  Requirements 

Obtain  Commitment  to  Requirements 

Manage  Requirement  Changes 

Maintain  Bidirectional  Traceability  of 
Requirements 

Identify  Inconsistencies  Between 
Project  Work  and  Requirements 
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Obtain  an  Understanding  of  Reqts. 


•  Establish  criteria  for  distinguishing  appropriate  requirements 

•  Establish  objective  criteria  for  the  acceptance  of  requirements 

•  Analyze  requirements  to  ensure  that  the  criteria  are  met 

•  Reach  an  understanding  of  the  requirements 
with  the  stakeholders 


Typical  Work  Products 

•  Lists  of  criteria  for 
distinguishing  appropriate 
requirement  providers 

•  Criteria  for  evaluation  and 
acceptance  of  requirements 

•  Results  of  analyses  against 
criteria 

•Agreed  to  set  of  requirements 


Sample  Key  Issues 


Missing  stakeholders 
Lack  of  appropriate 
requirements  results  in 
inadequate  verification,  rework 
_ or  system  rejection _ 

Failure  to  have  a  common 
understanding  of  requirements 
Insufficient  analysis  techniques 
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Obtain  Commitment  to  Requirements 


•  Assess  the  impact  of  requirements  on  existing 
commitments 

•  Negotiate  and  record  commitments 


Typical  Work  Products 


Sample  Key  Issues 


•Requirement  impact 
assessments 

•Documented 
commitments  to 
requirements  and 
requirement  changes 


Inadequate  assessments 

Existing  commitments  are  not 
well  known  or  defined 
Failure  to  negotiate  with 
balance  in  mind 
Failure  to  obtain  written 
commitment 
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Manage  Requirements  Changes 


•  Capture  all  requirements  and  requirements  changes 

•  Maintain  the  requirements  change  history  with  the  rationale  for 
the  changes 

•  Evaluate  the  impact  of  the  requirement  changes  from  the 
standpoint  of  the  stakeholders 

•  Make  the  requirements  and  change  data  available 


Typical  Work  Products 

•Requirement  impact 
assessments 

•Documented  commitments 
to  requirements  and 
requirement  changes 


Sample  Key  Issues 

Lagging  documentation  ^ 

Failure  to  plan  for  and  manage 
the  change  process 
Incomplete  impact 
_ assessments _ 

Lack  of  backup  plans  ) 
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Maintain  Bidirectional  Traceability 


•Ensure  the  source  of  lower  level  requirements  is  documented 
•Maintain  traceability  from  a  base  to  derived  requirements 
•Maintain  traceability  from  a  requirement  to  its  allocation 

•Maintain  horizontal  traceability  from  function  to  function  and 
across  interfaces 

•Generate  a  requirements  traceability  matrix 

Typical  Work  Products  Sample  Key  Issues 


•  Requirements  traceability  f  Lagging  documentation  A 

morriv 


matrix 

Requirements  tracking 
system 


Forgetting  to  verify  unwanted 
features  have  not  been  added  to  the 

system 


Missing  or  ineffective  requirements 
tracking  system 


Forgetting  to  verify  all  required 
features  exist 
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Identify  Inconsistencies 


•Review  the  project’s  plans,  activities  and  work  products  for 
consistency  with  the  requirements  and  changes 

•Identify  the  source  of  the  inconsistency  and  the  rationale 

•Identify  and  initiate  corrective  actions 


Typical  Work  Products 


Sample  Key  Issues 


•Documentation  of 
inconsistencies 
including  sources, 
conditions  and  rationale 

•Corrective  actions 


Waiting  too  long  to  identify 
inconsistencies 


Failure  to  verify  that  corrective 
action  was  completed 
Assuming  contractor  or 
someone  else  is  handling  this 


Incomplete  documentation 
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Poor  Requirements  Management ... 


Symptoms 

•  High  levels  of  re-work  throughout  the  project 

•  Requirements  are  accepted  by  staff  from  any  unauthorized  sources 

•  “Galloping”  requirements  creep 

•  Requirements  are  vague  and  subject  to  multiple  interpretations 

•  Missed  requirements  or  extraneous  (not-needed)  requirements 

•  Inability  to  prove  that  the  product  meets  the  approved  requirements 

•  Lack  of  Non-Functional  requirements 

•  Inadequate  or  missing  requirements  baselines 

Why  should  we  care? 

•  Solutions  that  don’t  match  user  needs  or  may  have  to  be  replaced  or 
retired  early 

•  Inability  to  hold  contractor  to  commitments 

•  Excessive  budget  consumption 

•  Requirements  errors  are  the  most  common  error  &  most  expensive  to  fix 

-  Requirements  error  are  likely  to  consume  25%  -  40%  of  the  total 
project  budget  when  not  caught  early 
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Recovery 


•  Assess  the  situation 

•  Don’t  perpetuate  the  problems 

•  Select  which  program  elements  to 
continue  during  assessment  and  repair 


•  Use  the  CMMI  Requirements  Management 
Process  Area  to: 

-Diagnose  problem  areas 
-Develop  corrective  action  plans 


•  Baseline  the  current  state,  and  track  changes  from  there 
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Prevention  Strategies 


•  Take  ownership — 

THEY  ARE  YOUR  REQUIREMENTS! 

•  Develop  and  manage  requirements  in  a  process 
context 

•  Ensure  your  process 

-  Avoids  key  issues 

-  Addresses  survival  tips 

•  Involve  all  stakeholders 

•  Dedicate  sufficient  resources 
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What  Do  I  Do  Now?  i 


If  you  are  in  an  early  program  phase: 

•  Establish  a  Configuration  Control  Board 

•  Ensure  that  user/operator  groups  participate  in  requirements 
process 

•  Provide  training  on  “good”  requirements  and  the  requirements 
management  process 

If  you  haven’t  released  your  RFP: 

•  Ensure  RFP  requires  documentation  of  change  management 
and  requirements  management  processes 

•  Ensure  the  RFP  specifies  that  the  PMO  approves  a 
requirements  baseline 

•  Ensure  system  interface  requirements  are  documented  in  the 
RFP 

•  Ensure  RFP  addresses  the  ‘ilities’  as  well  as  functional 
requirements 
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What  Do  I  Do  Now?  2 


If  you  are  still  negotiating  the  contract: 

•  Discuss  requirements  management  with  the  contractor 

•  Clearly  delineate  customer/contractor  roles  regarding 
requirements  development  and  management 

•  Potentially  modify  incentive  plan  to  encourage  some  of  the 
‘ilities’ 

If  you  are  already  executing  the  program: 

•  Can  you  trace  requirements  top-down  and  bottom-up? 

•  Are  software  requirements  effectively  documented  and 
decomposed  in  order  to  capture  all  derived  and  interface 
requirements? 

•  Consider  any  requirements  changes  on  a  case  by  case  basis 
and  consider  deferring  new  requirements 

•  Are  the  users/operators  still  involved  as  the  system  is  being 
developed? 
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Risk  Management  Purpose 


The  purpose  of  risk  management  is  to  identify  potential 
problems  before  they  occur,  so  that  risk-handling  activities 
may  be  planned  and  invoked  as  needed  across  the  life  of  the 
product  or  project  to  mitigate  adverse  impacts  on  achieving 
objectives. 
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Acquisition  Risk  Management 

For  Acquisition,  risk  identification  and  estimation  of  probability  of 
occurrence  and  impact,  particularly  for  those  risks  involved  in 
meeting  performance  requirements,  schedules,  and  cost  targets, 
largely  determines  the  acquisition  strategy. 

The  acquirer  has  a  dual  role,  first  in  assessing  and  managing 
overall  project  risks  for  the  duration  of  the  project,  and  second,  in 
assessing  and  managing  risks  associated  with  the  performance  of 
the  supplier. 

As  the  acquisition  progresses  to  the  selection  of  a  supplier,  the 
risk  specific  to  the  supplier’s  technical  and  management  approach 
becomes  important  to  the  success  of  the  acquisition. 
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Risk  Management  Goals  and  Practices 


Specific  Goal 

Specific  Practice 

Prepare  for  Risk 
Management 

•  Determine  Risk  Sources  and  Categories 

•  Define  Risk  Parameters 

•  Establish  a  Risk  Management  Strategy 

Identify  and 
Analyze  Risks 

•  Identify  Risks 

•  Evaluate,  Categorize,  and  Prioritize  Risks 

Mitigate  Risks 

•  Develop  Risk  Mitigation  Plans 

•  Implement  Risk  Mitigation  Plans 
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Determine  Risk  Sources  &  Categories 


•Determine  risk  sources  and  categories 


Typical  Work  Products 


Sample  Key  Issues 


•Risk  sources  lists 
(Internal  &  External) 

•Risk  categories  lists 


Including  acquiring  office  risks 
as  well  as  vendor  risks 
Not  including  all  stakeholder 
_ viewpoints _ 

Skipping  ahead  to  risk 
identification 
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Define  Risk  Parameters 


•Define  the  parameters  used  to  analyze  and  categorize 
risks. 

•Define  the  parameters  used  to  control  the  risk 
management  effort. 


Typical  Work  Products 

•Risk  evaluation, 
categorization,  and 
prioritization  criteria 

•Risk  management 
requirements  (control  & 
approval  levels, 
reassessment  intervals,  etc.) 


Sample  Key  Issues 


Not  tailoring  risk  categories  to 
_ specific  project _ 

Inability  to  get  agreement  on 
risk  category  thresholds 
Skipping  ahead  to  risk 
identification 
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Establish  a  Risk  Management  Strategy 


•Establish  and  maintain  the  strategy  to  be  used  for  risk 
management. 


Typical  Work  Products 

•Project  risk  management 
strategy 


Sample  Key  Issues 


Lack  of  established  process  to 
sustain  continuous  risk 
management  over  time 

Failure  to  evaluate  the 
supplier’s  risk  management 
approach  for  the  potential  of  a 
shared  risk  data  base 


Failure  to  document  the 
strategy 
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Identify  Risks 

•Identify  and  document  the  risks. 


Typical  Work  Products 

•List  of  identified  risks, 
including  the  context, 
conditions,  and 
consequences  of  risk 
occurrence 


Sample  Key  Issues 


Failure  to  include  internal 
project  risks  as  well  as 
technical  risks  related  to  the 
_ development _ 

Relying  on  only  one  source  of 
risk  identification 


Failure  to  distinguish  between 
project  risks  and  project  issues 


Incomplete  risk  statements 
source,  condition,  context 
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Evaluate,  Categorize,  &  Prioritize  Risks 


•Evaluate  and  categorize  each  identified  risk  using  the 
defined  risk  categories  and  parameters 

•Determine  the  relative  priority  of  each  risk 


Typical  Work  Products 


Sample  Key  Issues 


•  List  of  risks,  with  a  priority 
assigned  to  each  risk 


Inability  to  achieve  consensus 
on  risk  categorization 
Unclear  understanding  of 
_ categories _ 

Uneven  application  of  risk 
categories 
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Develop  Risk  Mitigation  Plans 


•Develop  a  risk  mitigation  plan  for  the  most  important  risks 
to  the  project,  as  defined  by  the  risk  management  strategy 


Typical  Work  Products 

•Documented  handling  options 
for  each  identified  risk 

•Risk  mitigation  &  contingency 
plans 

•  List  of  those  responsible  for 
tracking  and  addressing  each 
risk 

©2005  by  Carnegie  Mellon  University 


Sample  Key  Issues 

^  Risks  without  accountability  ^ 

Unclear  understanding  of 
mitigation  approaches 
Mitigation  triggers  not 
,  communicated  > 
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Implement  Risk  Mitigation  Plans 


•Monitor  the  status  of  each  risk  periodically  and  implement 
the  risk  mitigation  plan  as  appropriate 


Typical  Work  Products 

•Updated  lists  of  risk  status 

•Updated  assessments  of  risk 
likelihood,  consequence,  and 
thresholds 

•Updated  lists  of  risk-handling 
options 

•Risk  mitigation  plans 


Sample  Key  Issues 


Lagging  documentation 

Plans  don’t  match  overall 
strategy  set  forth  for  the  project 

Incentivize  risk  communication 
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Poor  Risk  Management ... 


Symptoms 

•  Risks  are  being  ignored 

•  No  activity  on  documented  risk  items,  static  risk  database 

•  Known  risks  to  project  staff  are  a  surprise  to  management 

•  No  risk  ownership 

•  Every  time  a  new  problem  manifests,  a  new  management 
technique  is  tried 

Why  should  we  care? 

•  The  project  may  escape  some  of  the  “bullets,”  but  not  all  of 
them 

•  No  lessons  learned  for  future  projects  means  making  the  same 
mistakes  on  multiple  projects 

•  Repeated  project  failures  due  to  unforeseen  (but  predictable) 
risks  costs  you  and  your  organization 
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Recovery 

•  Hold  a  focused  working  session  to 

-  Identity,  classify,  and  prioritize  all  current  risks 

-  Revise  the  risk  communication  and  documentation 
plan 

•  Consider  an  independent  assessment  of  program  risk 

•  Develop  a  distributed  risk  repository 

-  Local  risk  management  at  contractor  sites  and  sub¬ 
contractor  sites 

-  Escalate  risks  according  to  acquirer  approved 
criteria 

•  Train  project  office  personnel  in  risk  management 

•  Hold  a  risk  management  review  to  include  a  review  of 
mitigation  plans 
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Prevention  Strategies1 


•  Start  a  risk  management  program  on  Day  1  of 
the  program 

•  Ensure  that  acquiring  office  staff  has  had 
appropriate  risk  management  training 

•  Use  multiple  methods  to  identify  risk  sources: 

-  periodic  risk  reporting  -  brainstorming 

-  voluntary  risk  reporting  -  risk  report  forms 

-  taxonomy-based  questionnaire  -TBQ  interviews 
(TBQ) 
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Prevention  Strategies  2 


•  Add  language  to  RFPs  and  contracts  that  specify  how  risks  are 
to  be  reported  to  the  PMO 

•  Encourage  decentralization  of  risk  identification  and  analysis 
following  an  organizationally  defined  process 

•  Establish  and  maintain  a  schedule  of  joint  risk  reviews  with  all 

•  contractors  throughout  the  program,  including  joint 
prioritization  of  the  most  important  risks  to  the  program 

•  Find  ways  to  reward  contractors  for  early  identification  of 
issues  and  risks 

•  Define  a  process  and  criteria  for  escalating  risks  to  the  next 
higher  level 
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What  Do  I  Do  Now?  ^ 

if  you  are  in  an  early  program  phase: 

•  Establish  a  PMO  risk  management  process 

•  Review  the  acquisition  strategy  for  programmatic  risks 

•  Put  PMO  risk  mitigation  plans  in  place 

If  you  haven’t  released  your  RFP: 

•  Ensure  RFP  requires  explanation/evidence  of  risk 
management  and  mitigation  processes  and  strategies 

•  Ensure  RFP  addresses  programmatic  risks  previously 
identified 

•  Ensure  RFP  requires  bidders  to  document  risks 
associated  with  the  program 

•  Establish  a  method  for  evaluating  the  risk  of  each 
proposal 
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What  Do  I  Do  Now?  2 


If  you  are  still  negotiating  the  contract: 

•  Include  a  risk  management  program  in  the  contract 

•  Ensure  risk  management  tasks/strategy  are  properly 
aligned  with  development  and  acquisition  strategies 

If  you  are  already  executing  the  program: 

•  Communicate  regularly  with  the  contractor  about  program 
risks  and  status 

•  Ensure  PMO  staff  has  the  knowledge  to  identify  both 
technical  and  non-technical  risk  items 

•  Consider  revising  the  incentive  or  award  fee  to  include  the 
risk  management  program  as  an  incentive  area 

•  Consider  conducting  independent  risk  assessments 
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Summary  of  Survival  Skills  Approach 

•  Review  process  areas,  specific  practices,  typical 
work  products 

•  Include  Acquisition  amplifying  information 
including  sample  key  issues 

•  Identify  symptoms 

•  List  prevention  approaches 

•  Give  practical  tips  on  what  to  do  next  (tailored  to 
where  you  are  in  the  process) 
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Contact  Information 


Brian  Gallagher 

Director,  Acquisition  Support  Program 
Software  Engineering  Institute 
Tel  412.268.7157 
Email  bg@sei.cmu.edu 

Joseph  P.  Elm 

Sr.  Technical  Staff,  Acquisition  Support  Program 
Software  Engineering  Institute 
Tel  412.268.9132 
Email  jelm@sei.cmu.edu 

John  W.  Mishler 

Visiting  Scientist,  Acquisition  Support  Program 
Software  Engineering  Institute 
Tel  410.414.9219 
Email  jmishler@sei.cmu.edu 
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